verify-stage: add /pharn-verify product command and two-layer verify gate#27
Conversation
…gate Introduce the sixth product-pipeline stage with floor-owned verdict (check-verify.mjs) and advisory verifier annotations only. Co-authored-by: Cursor <cursoragent@cursor.com>
📝 WalkthroughWalkthroughThis PR adds documentation-only artifacts: a new ChangesVerify stage command and documentation
Estimated code review effort: 2 (Simple) | ~12 minutes Sequence Diagram(s)sequenceDiagram
participant Command as "/pharn-verify"
participant HashChain as "check-plan-spec-agree.mjs"
participant Gates as "Deterministic Gate Suite"
participant Verdict as "check-verify.mjs"
participant Reports as "verify-report.json / VERIFY.md"
Command->>HashChain: run spec-plan hash-chain check
HashChain-->>Command: exit code (GREEN/RED)
Command->>Gates: run deterministic gates at HEAD
Gates-->>Command: {gate-id: exit-int} map
Command->>Verdict: compute verdict from gate results
Verdict-->>Command: PASS/FAIL/INCONCLUSIVE
Command->>Reports: emit machine + human artifacts
Possibly related PRs
🚥 Pre-merge checks | ✅ 3 | ❌ 2❌ Failed checks (2 warnings)
✅ Passed checks (3 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
…ust audit Clarify that gate commands come from the user's suite while §3b eval-pair paths are PLAN-derived but bounded to file operands only; record the GATE 2 fix in SHIP.md. Co-authored-by: Cursor <cursoragent@cursor.com>
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.dev/features/verify-stage/REVIEW.md:
- Around line 24-25: The `check-verify.mjs` input description is too narrow
because it implies the helper only receives the gate→exit-code map; update the
wording in `REVIEW.md` to reflect that `check-verify.mjs` is invoked with
`results.json` and `--feature <name>`, and rephrase the claim around
`verdict-ownership` to say findings do not affect the verdict rather than saying
it has a sole input.
In @.dev/features/verify-stage/VERIFY.md:
- Around line 18-23: Clarify the VERIFY.md pass criteria so PASS is not
described as being covered by npm run check alone. Update the explanation around
the check flow and the gating logic to explicitly state that the full PASS
outcome also depends on the additional validate and structural:* gates, using
the nearby wording around npm run check, validate, and structural:* to keep the
relationship unambiguous.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 77921223-b2b8-4a42-964a-a42a7675e00e
📒 Files selected for processing (9)
.claude/commands/pharn-verify.md.dev/features/verify-stage/GRILL.md.dev/features/verify-stage/PLAN.md.dev/features/verify-stage/REGRESSION.md.dev/features/verify-stage/REVIEW.md.dev/features/verify-stage/SHIP.md.dev/features/verify-stage/VERIFY.md.dev/features/verify-stage/regression-report.json.dev/features/verify-stage/verify-report.json
| and verdict-ownership is shown **structural** (the helper's sole input is the gate→exit-code map — it | ||
| cannot receive a finding). "ensures the feature is correct" is explicitly **struck** as the P0 disease. |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
Tighten the check-verify.mjs input claim.
check-verify.mjs is invoked with results.json plus --feature <name>, so it does not take only the gate→exit map. Rephrase this as “findings do not affect the verdict” instead of “sole input.”
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.dev/features/verify-stage/REVIEW.md around lines 24 - 25, The
`check-verify.mjs` input description is too narrow because it implies the helper
only receives the gate→exit-code map; update the wording in `REVIEW.md` to
reflect that `check-verify.mjs` is invoked with `results.json` and `--feature
<name>`, and rephrase the claim around `verdict-ownership` to say findings do
not affect the verdict rather than saying it has a sole input.
| - The `format:check` + `lint:md` + `lint` + `test` set is exactly the repo's `npm run check` aggregate, so | ||
| the verdict tracks the full `npm run check` (L9 — cited, not restated, P4). | ||
| - The `structural:*` gate is the one committed eval pair the feature surface ships | ||
| (`pharn-review/trust-fence/evals/expected/expected-injection-comment.json` ↔ | ||
| `.dev/features/trust-fence/findings.json`). This increment added **no** new eval pair (it ships a | ||
| floor-ignored command + audit scaffolding), so this pre-existing pair is the only `structural:*` gate. |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
Clarify that PASS is broader than npm run check.
Lines 18-19 say this set is “exactly” the repo’s npm run check aggregate, but lines 12 and 16 add validate and structural:* gates on top. As written, a clean npm run check still wouldn’t guarantee PASS.
♻️ Proposed wording fix
- The `format:check` + `lint:md` + `lint` + `test` set is exactly the repo's `npm run check` aggregate, so
- the verdict tracks the full `npm run check` (L9 — cited, not restated, P4).
+ The `format:check` + `lint:md` + `lint` + `test` set matches the repo's `npm run check` aggregate.
+ The verify verdict also depends on the `validate` and `structural:*` gates above.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| - The `format:check` + `lint:md` + `lint` + `test` set is exactly the repo's `npm run check` aggregate, so | |
| the verdict tracks the full `npm run check` (L9 — cited, not restated, P4). | |
| - The `structural:*` gate is the one committed eval pair the feature surface ships | |
| (`pharn-review/trust-fence/evals/expected/expected-injection-comment.json` ↔ | |
| `.dev/features/trust-fence/findings.json`). This increment added **no** new eval pair (it ships a | |
| floor-ignored command + audit scaffolding), so this pre-existing pair is the only `structural:*` gate. | |
| The `format:check` + `lint:md` + `lint` + `test` set matches the repo's `npm run check` aggregate. | |
| The verify verdict also depends on the `validate` and `structural:*` gates above. | |
| - The `structural:*` gate is the one committed eval pair the feature surface ships | |
| (`pharn-review/trust-fence/evals/expected/expected-injection-comment.json` ↔ | |
| `.dev/features/trust-fence/findings.json`). This increment added **no** new eval pair (it ships a | |
| floor-ignored command + audit scaffolding), so this pre-existing pair is the only `structural:*` gate. |
🧰 Tools
🪛 LanguageTool
[style] ~18-~18: Consider an alternative for the overused word “exactly”.
Context: ...k+lint:md+lint+testset is exactly the repo'snpm run check` aggregate, s...
(EXACTLY_PRECISELY)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.dev/features/verify-stage/VERIFY.md around lines 18 - 23, Clarify the
VERIFY.md pass criteria so PASS is not described as being covered by npm run
check alone. Update the explanation around the check flow and the gating logic
to explicitly state that the full PASS outcome also depends on the additional
validate and structural:* gates, using the nearby wording around npm run check,
validate, and structural:* to keep the relationship unambiguous.
Summary
/pharn-verify, the sixth product-pipeline stage (spec → plan → grill → build → regress → verify → ship), as a command-only increment with no new floor primitive./pharn-dev-verify's two-layer pattern to the product side: the floor layer owns the verdict viacheck-verify.mjs(absolute exit-code threshold over project gates + structural eval pairs); the advisory layer (role: verifiercapabilities) annotates only and never flips the verdict (fix Add eval-format contract (structural vs semantic assertion split) #3). Zero verifiers exist today (P7) → floor gates only.check-verify.mjs,count-verifiers.mjs,check-plan-spec-agree.mjsas the fourth spec→plan hash-chain consumer,check-structural.mjs) and emitsfeatures/<name>/verify-report.json+features/<name>/VERIFY.md..dev/features/verify-stage/(plan, grill, review, ship, regression/verify reports).Test plan
npm test— floor and hook suites stay greennode .dev/floor/validate.mjs .— capability count remains 1 (command is floor-ignored)/pharn-verifyagainst a feature withfeatures/<name>/PLAN.md+SPEC.mdand confirmverify-report.json+VERIFY.mdemit with a deterministicPASS/FAILverdictcheck-plan-spec-agree.mjs)FAILfromcheck-verify.mjs verdict(verifier findings do not override)count-verifiers.mjsreports zero registered verifiers (floor-only path exercised)Made with Cursor
Summary by CodeRabbit
New Features
Documentation
Bug Fixes